IP Multimedia services provide a dynamic combination of voice, video, messaging, data, etc. within the same session. By growing the number of basic applications and the media which it is possible to combine, the number of services offered to the end users will grow, and the inter-personal communication experience will be enriched. This will lead to a new generation of personalised, rich multimedia communication services, including so-called “combinational IP Multimedia” services.
The Universal Mobile Telecommunications System (UMTS) is a third generation wireless system designed to provide higher data rates and enhanced services to users. The UMTS architecture includes a subsystem known as the IP Multimedia Subsystem (IMS) for supporting traditional telephony as well as new IP multimedia services. IMS provides key features to enrich the end-user person-to-person communication experience through the use of standardised IMS Service Enablers, which facilitate new rich person-to-person (client-to-client) communication services as well as person-to-content (client-to-server) services over IP-based networks. The IMS is able to connect to both PSTN/ISDN (Public Switched Telephone Network/Integrated Services Digital Network) as well as the Internet. It is expected that IMS will be integrated into current and future Long Term Evolution (LTE) deployments.
The IMS makes use of the Session Initiation Protocol (SIP) to set up and control calls or sessions between user terminals (or terminals and application servers). The Session Description Protocol (SDP), carried by SIP signalling, is used to describe and negotiate the media components of the session. Whilst SIP was created as a user-to-user protocol, IMS allows operators and service providers to control user access to services and to charge users accordingly. The 3GPP has chosen SIP for signalling between a User Equipment (UE) and the IMS as well as between the components within the IMS.
By way of example, FIG. 1 illustrates schematically how the IMS fits into the mobile network architecture in the case of a GPRS/PS access network (IMS can of course operate over other access networks). Call/Session Control Functions (CSCFs) operate as SIP proxies within the IMS. The 3GPP architecture defines three types of CSCFs: the Proxy CSCF (P-CSCF) which is the first point of contact within the IMS for a SIP terminal; the Serving CSCF (S-CSCF) which provides services to the user that the user is subscribed to; and the Interrogating CSCF (I-CSCF) whose role is to identify the correct S-CSCF and to forward to that S-CSCF a request received from a SIP terminal via a P-CSCF.
Within the IMS service network, Application Servers (ASs) are provided for implementing IMS service functionality. Application Servers provide services to end users in an IMS system, and may be connected either as end-points over the 3GPP defined Mr interface, or “linked in” by an S-CSCF over the 3GPP defined ISC interface. In the latter case, Initial Filter Criteria (IFC) are used by an S-CSCF to determine which Applications Servers should be “linked in” during a SIP Session establishment (or indeed for the purpose of any SIP method, session or non-session related). The IFCs are received by the S-CSCF from an HSS during the IMS registration procedure as part of a user's Subscriber Profile.
IMS implements flexible user charging schemes in respect of IMS services. In particular, IMS allows operators to charge for value added services over and above the mere transfer of data. For a given IMS session, it is possible that a number of IMS network elements will generate data required for offline and/or online charging. This is likely to become more common as the IMS evolves such that multiple ASs are used per session. To decrease the need for correlation at a (central) charging control function which collects data from multiple IMS charging elements, especially in the case of online charging (e.g. used for prepaid subscribers), it is useful to concentrate charging information at a single network element per session and to transfer all of this charging information from that single element to the charging control function. This will of course require that unique information available in other network elements be transported to the selected charging point.
One method to achieve the transport of charging information between IMS network elements within SIP messages involves the use of the SIP private header P-Charging-Vector (PCV). PCV is defined in RFC3455 with the parameters:                icid-value; the IMS Charging Identity Value. The icid-value is a charging value that identifies a dialogue or a transaction outside a dialogue. It is used to correlate charging records. An icid-value must be a globally unique value.        icid-gen-addr; the address of the SIP proxy that creates the icid-value.        orig-ioi; the originating Inter Operator Identifier.        term-ioi; the terminating Inter Operator Identifier.        generic-param; this parameter allows for the use of further parameters without the need to specify these individually. A network operator may define such further parameters for use within its own network domain in order to transport network specific information within the PCV.        
The treatment of these parameters in the different network elements is described in TS 24.229. This treatment is different for each parameter and also dependent on the network element. [It is noted that, as with other SIP privacy headers, the PCV header is not included in a SIP message sent between networks if no trust relationship exists between them.] An extension to the PCV is described in 3GPP TS 24.229 (access-network-charging-info).
The generic-param may be used to carry charging related information over and above that provided for by the existing icid-value, icid-gen-addr, orig-ioi, and term-ioi parameters described above. In addition, further parameters could be specified for this purpose. However, both of these options would require that all network elements through which a message carrying the parameter can pass are updated to include appropriate behaviour, i.e. the added information must be known and understood by all of the affected network elements. This would be a complicated process particularly in a multi-vendor solution, i.e. where different vendors supply different parts of an operator's network.